Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typesafe Splipy, again #175

Open
wants to merge 29 commits into
base: master
Choose a base branch
from
Open

Typesafe Splipy, again #175

wants to merge 29 commits into from

Conversation

TheBB
Copy link
Member

@TheBB TheBB commented Feb 12, 2024

This PR does the following:

  • Add type hints to nearly every module and function in Splipy.
  • Use the mypy type checker to check type correctness during the CI phase.
  • Use the ruff linter to check a large variety of good practices in the code.
  • Use the ruff formatter to enforce a standard code style.

When this is merged, CI fill fail if:

  • pytest: if the tests fail, obviously.
  • mypy: if the type checker fails, even if the tests succeed.
  • ruff: the linter complains about anything.
  • ruff: the style isn't being followed. 😈

I have written a nice Makefile that helps developers out, and I've written how to use it in the readme. In particular, make lint and make format will automatically fix as many issues with the 3rd and 4th failure modes as possible. There are some it can't fix, and type and test failures will need to fixed manually.

The CI is configured to NEVER fix anything automatically - it will just check.

The following should be noted. The way I see it this addresses all the issues in #174.

  • BSplineBases.evaluate returns either a sparse or a dense array. There are now two new methods, evalute_sparse and evaluate_dense. The evaluate method still exists.
  • SplineObject.split returns a SplineObject or a list of SplineObjects based on information that can't be detected in types (it returns a single spline if the spline is periodic and is being split at only one point). This is the most serious one. I have added spit_periodic which takes a single knot and requires that the spline be periodic - it returns a single new spline that isn't periodic. I have also added split_nonperiodic which takes one or more knots, requires that the spline be non-periodic and always returns a list. I have also added split_many which has the same requirements as split does but which always returns a list, even in the periodic single-knot case. The method split remains in place as before.
  • Curve.curvature and Curve.torsion used to not obey the Splipy convention that evaluation functions return a single output if given a scalar, and should return an array of outputs if given a list of inputs, even if that input is a list with only one element. This has been fixed.
  • Linting and type checking is ignored for splipy.utils.bisect. This is a pure copy of Python's bisect module from Python 3.10 that we can remove for good when we drop support for Python 3.9.
  • Type checking is ignored for splipy.io.grdecl. I tried, but this code is pretty rough, and at this point unlikely to see serious use for a while.

This is strictly speaking ready to merge but let's leave it for a little while so my brain can sleep on it. I don't expect anyone to literally read all the changes - many of them are automatized lint-checks, but a cursory glance might be good.

@TheBB
Copy link
Member Author

TheBB commented Feb 15, 2024

35 type errors still to go (out of about 500)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant